fix(filelocker): remove stale .stop file when Lock times out#1373
Open
SAY-5 wants to merge 2 commits into
Open
fix(filelocker): remove stale .stop file when Lock times out#1373SAY-5 wants to merge 2 commits into
SAY-5 wants to merge 2 commits into
Conversation
When Lock() creates a .stop file to signal release to the current holder and then times out without acquiring the lock, the .stop file was previously only removed by a successful Unlock() — which is never called for a failed acquisition. The leftover file would persist on disk until the next successful Unlock() of the same upload ID. On filesystems where flock() can return ErrBusy spuriously (notably SMB/CIFS), this caused failed acquisitions to leave permanent stale state that broke all subsequent retries. Clean up the .stop file directly in the ctx.Done() branch. Fixes tus#1372.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1372.
When
Lock()creates a.stopfile to signal release to the current holder and then times out without acquiring the lock, the.stopfile was previously only removed by a successfulUnlock()— which is never called for a failed acquisition. The leftover file persisted on disk until the next successfulUnlock()of the same upload ID.On filesystems where
flock()can returnErrBusyspuriously (notably SMB/CIFS), failed acquisitions left permanent stale state that broke all subsequent retries withERR_LOCK_TIMEOUTeven when no other process held the lock.This patch cleans up the
.stopfile directly in thectx.Done()branch ofLock()and adds a regression test that assertsone.stopis gone after a contendedLock()times out without the held lock being released.